Read the compared contents once, in the background - #2840
Open
vogella wants to merge 1 commit into
Open
Conversation
Contributor
Test Results 54 files + 54 54 suites +54 59m 47s ⏱️ + 59m 47s For more details on these failures, see this check. Results for commit fee6afc. ± Comparison against base commit 196a2b9. ♻️ This comment has been updated with latest results. |
vogella
force-pushed
the
compare-prefetch-contents
branch
from
July 31, 2026 08:10
9cdd11b to
c8e3000
Compare
Opening a compare editor read each side three times: once for content type detection, once for the text heuristic and once for the document shown in the viewer, all three on the UI thread and each one paying whatever the provider charges for a stream. For an EGit revision that means inflating the blob and running the smudge filters three times over. The background job that prepares the input now reads the contents once and the sniffing and the merge viewer are served from that. Elements backed by a shared document are skipped, since those come from the file buffer and never read a stream anyway. An entry is dropped as soon as it became a document, so at most one input's contents are held at a time. CompareOpenEfficiencyTest's bound drops from 3 reads per side to 1. Contributes to eclipse-platform#2795
vogella
force-pushed
the
compare-prefetch-contents
branch
from
July 31, 2026 14:34
c8e3000 to
fee6afc
Compare
vogella
marked this pull request as ready for review
July 31, 2026 14:34
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Opening a compare editor read each side three times: once for content type detection, once for the text heuristic and once for the document shown in the viewer. All three happened on the UI thread and each one paid whatever the provider charges for producing a stream; for an EGit revision that means inflating the blob and running the smudge and EOL filters three times over.
The background job that prepares the input now reads the contents once, and both the sniffing and the merge viewer are served from that. Elements backed by a shared document are skipped, since those are served from the file buffer and never read a stream anyway, which is exactly the local side of a typical comparison. An entry is dropped as soon as it became a document, so at most one input's contents are held at a time.
CompareOpenEfficiencyTest's bound drops from 3 reads per side to 1, and I verified that the bound really depends on the prefetch: with the prefetch call removed the test reports 3 again.Contributes to #2795